super simple codeを目指したい
#設計原則 #プログラミング #opinionated #エンジニアリング
@flaviocopes: https://t.co/7XcGs3GUnj
https://pbs.twimg.com/media/Fe4YU9NX0AAKAWR.jpg
Abstractionはレイヤードアーキテクチャ、DDDあたりの沼がある
過剰なアーキテクチャが生まれる背景
@sonatard: OOP -> Design Patterns -> Abratractionsという流れはまさに自分に当てはまるw
一方で後半のsuper simple codeは経験した人の感覚であり言語化されることが少ないので、言語化してアウトプットしていきたい
#デザインパターン
koushisa.icon
抽象化のプロセスで汎用的に通ずる本質はある
1. 対象の性質を理解する
2. ステレオタイプなどの意味的な分類
3. プログラムを十分に小さくし、責務を深くする
4. 変性を利用したポリモーフィズム
5. 関数型プログラミングや計算幾何学の根底にある数学の定理のようなアプローチ
共通化と抽象化
抽象化とモデリングの違い
GUIのデータアーキテクチャと状態管理の変遷とかまとめたりアーキテクチャ宇宙飛行士やってた中で最近大事だと思ってるのは
1. コード量を減らす(Write less code)
2. 考えながら作る(Write code thinking)
3. 決断を遅らせる
4. アーキテクチャの育て方
5. これらを支えるテスト容易性の高い関数設計と捨てやすさ及び境界づけられたコンテキスト
バチッと一貫性を持った設計をキメるより、ポイントを抑えて変更を前提とした捨てやすさが大事
一度にすべて作り切る必要はないし、段階的に理解を重ねながら作る
テストラスト開発
犠牲的アーキテクチャ
セーフティネットとしての設計
アーキテクチャ宇宙飛行士への疲労感と焦燥感
ベスト/グッドプラクティスよりもアンチパターンを優先的に理解する
失敗例を体に叩き込む
自分でtry & errorを繰り返しながらトレードオフとアンチパターンを考察する
その過程で様々な設計原則を知る
可読性、理解容易性、正しさへの迷いは作業者のバックグラウンドに依存する
言語である以上、「読み手に依存する」
語は私たちが与えた意味を持つ
プログラミングに深い興味があってもっと上を目指すなら圏論とか学びつつ関数型プログラミング由来の思考に触れてみるといいかもしれない
ミクロな視点でコンポーサブルな関数設計を汎化しており、示唆に富んでいる
ライブラリのソースコード読むと「あ、これモナドっぽいやつだな」みたいになって理解に役立つ
最近感動したのはRecoil > Loadable
実際に活かすとなると、読む側にも一定の学習ハードルをかけるので難しいとは思うけどもkoushisa.icon
関連: 良い設計の標準化やプログラミング能力の底上げに対する気持ちを残しておく
2023/12/23
これ書いて1年後に見た
最近はプログラミングや設計よりは、QAに関心がある
主戦場であるフロントエンドについては
圏論や関数型プログラミングを極めても、外部品質の担保の知識がないと全体最適に至るのが難しい
行き過ぎると意識の高さに周りが付いて来ず結果使うのが面倒くさいのに大したことをしてくれないソースコードになる
質とスピードを両立させるとき、経験上はコード以外にボトルネックがある
現実的にフレームワーク置き換えだったり作り替えは数年スパンではあるので、そこで必要となるのはE2Eだったり少しずつ置き換えられるようになっているかとかではないか
エンジニアリングの本質は問題定義能力
この辺りの思い
AIをソフトウェア開発へ取り込む際のテストにLLMsを活用する可能性に想いを馳せる
作りたいものに対して世の中の技術スタックは複雑になりすぎているという雰囲気もありつつ、技術トレンドの新陳代謝やサンクコストを考えるといまのkoushisa.iconにとってはQAがROIが高い
(自分の環境においては) React が Easy と Simple を両立していて理想的である
経営目線でソフトウェアの設計やテストの類をコストと捉えるか投資として捉えるかのマインドセットの違い
テスト手法にトレンドがあってはいけない。テストは投資であって、長期的に安定しているべき